Why?

Dart web builds use JavaScript number semantics, so raw Dart int cannot safely represent the full 64-bit value space used by Fory xlang integer encodings. The Dart runtime needs browser-compatible buffer, generated serializer, and 64-bit wrapper implementations that preserve wire compatibility instead of silently corrupting JS-unsafe values.

What does this PR do?

• Adds Dart web support through conditional native/web implementations for Buffer, generated cursors, and Int64 / Uint64 value and list wrappers.
• Updates code generation and serializers to handle full-range signed and unsigned 64-bit fields on web, while keeping Dart int fast paths for JS-safe values.
• Adds explicit range checks so web builds reject JS-unsafe Dart int conversions instead of writing or reading imprecise bytes.
• Extends Dart serializer, buffer, generated-field, numeric-wrapper, typed-array, and time tests for 64-bit edge cases and browser behavior.
• Adds Chrome test coverage to CI with dart test -p chrome for the Dart package.
• Documents Dart web support, 64-bit integer rules, custom serializer guidance, and troubleshooting steps.

Related issues

Closes #3600

AI Contribution Checklist

• Substantial AI assistance was used in this PR: yes / no
• If yes, I included a completed AI Contribution Checklist in this PR description and the required AI Usage Disclosure.
• If yes, my PR description includes the required ai_review summary and screenshot evidence of the final clean AI review results from both fresh reviewers on the current PR diff or current HEAD after the latest code changes.

Does this PR introduce any user-facing change?

Yes. Dart users can now use generated serializers and manual serializers on web/browser targets. Full-range 64-bit values should use Int64 or Uint64; Dart int fields remain limited to JS-safe values on web.

• Does this PR introduce any public API change?
• Does this PR introduce any binary protocol compatibility change?

Benchmark